[aes,dv] Recalculate aad/ptx length when splitting message #28
Conversation
hw/ip/aes/dv/env/aes_message_item.sv
Outdated
| len_aad_data = {<<8{len_aad_data_conc}}; | ||
| // Check if the calculated len(aad) || len(data) matches the length we wrote | ||
| // into the DUT. | ||
| if (len_aad_data != item.data_in) begin |
There was a problem hiding this comment.
I think this is reasonable but I have a question: in case we split messages due to FI testing, which one is the length accounting for the splitting? Is it item.data_in (the value passed to the DUT) or is it aad_length | message_length (I see this value is randomized in this file and then extended upon adding more stuff).
Depending on that, we may want to perform the tag comparison but update the DPI call. Because what the try_recover() verifies, is that after a fault, the DUT can be reset and successfully do an encryption/decryption.
There was a problem hiding this comment.
Thanks for your review, @vogelpi.
I've actually found a more elegant solution that does not ignore the tag check for those messages. Instead, the new len(aad) || len(data) now gets re-computed in the base sequence where we split up the message and we're now updating the AES_GCM_TAG aes_seq_item . Now, the tag comparison can be conducted even though we are splitting up messages in the try_recover() function.
When performing alert or FI tests, the try_recover() function in the base sequence splits up messages. E.g.: |AAD|AAD|PTX|PTX|TAG| could be split up into |AAD|PTX|PTX|TAG when there is an error injected at the first AAD block. This is problematic as now len(aad) || len(data), which is the data_in of the TAG block, does not match anymore. Hence, the tag comparison fails. This commit now recomputes len(aad) || len(data) at puts it into the correct AES_GCM_TAG item. Signed-off-by: Pascal Nasahl <[email protected]>
nasahlpa
force-pushed
the
aes_gcm_dv_fix_fi
branch
from
bb992c2 to
593ae92
Compare
nasahlpa
changed the title
When performing alert or FI tests, the try_recover() function in the base sequence splits up messages.
E.g.:
|AAD|AAD|PTX|PTX|TAG|
could be split up into
|AAD|PTX|PTX|TAG
when there is an error injected at the first AAD block.
This is problematic as now len(aad) || len(data, which is the data_in of the TAG block, does not match anymore. Hence, the tag comparison fails.